The National Institute of Standards and Technology (NIST), an agency of the U.S. Department of Commerce's Technology Administration, announced the approval of the Federal Information Processing Standard (FIPS) for the Advanced Encryption Standard (AES) as described in FIPS Publication 197 (FIPS PUB 197), which is hereby incorporated by reference into the present specification. This standard specifies a symmetric encryption algorithm that may be used by U.S. Government organizations to protect sensitive, but unclassified, information.
The AES was designed to replace the Digital Encryption Standard (DES). However, Triple DES remains an approved algorithm for U.S. Government use for the foreseeable future. Single DES is being phased out of use, and is currently permitted only in legacy systems. DES and Triple DES are described in FIPS PUB 46-3, which is incorporated by reference into the specification of the present invention.
The length of a cryptographic key (hereinafter referred to as a key) used with AES may be either 128 bits, 192 bits, or 256 bits. For these key lengths, there are 3.4×10^38 possible 128-bit keys, 6.2×10^57 possible 192-bit keys, and 1.1×10{circumflex over ( )}77 possible 256-bit keys or on the order of 10^21 more keys than are possible with the 56-bit key required by DES (i.e., 7.2×10^16 possible 56-bit keys).
Any cryptographic method is rendered useless if an adversary can obtain the key used to encrypt information, which is commonly referred to as a content-encryption key or CEK. Therefore, a secure key management is needed for any encryption method including AES.
One approach to key management is to protect the CEK by encrypting it with another cryptographic key, which is commonly referred to as a key-encryption key or KEK. Two such methods are described in a document published in 1999 by The Internet Society concerning Cryptographic Message Syntax entitled “RFC2630.” This document describes two methods of encrypting, or wrapping, CEKs for use with Triple DES and RC2, respectively.
The first step of the Triple DES key wrapping method is setting odd parity for each of the DES key octets comprising the CEK.
The second step of the Triple DES key wrapping method is forming ICV by computing an 8 octet key checksum value on CEK. The preferred method of forming ICV is by computing a 20 octet message digest on the CEK using the Secure Hashing Algorithm (SHA-1) and using the most significant, or first, eight octets of the message digest value as ICV.
The third step of the Triple-DES key wrapping method is forming CEKICV by concatenating CEK and ICV.
The fourth step of the Triple-DES key-wrapping method is generating an initialization vector (IV) as 8 random octets.
The fifth step of the Triple-DES key-wrapping method is forming TEMP1 by encrypting CEKICV in DES Cipher Block Chaining (CBC) mode using a KEK and IV.
The sixth step of the Triple-DES key-wrapping method is forming TEMP2 by concatenating IV and TEMP1.
The seventh step of the Triple-DES key-wrapping method is forming TEMP3 by reversing the order of the octets in TEMP2. That is, swapping the most significant, or first, octet with the least significant, or last, octet, and so on.
The eighth, and last, step of the Triple-DES key-wrapping method is encrypting TEMP3 in CBC mode using the KEK and 0x4adda22c79e82105 as IV. The length of the resulting ciphertext is 40 octets.
This Triple DES key wrapping method requires that a different IV be used when the same CEK is wrapped using a different KEK.
The first step of the RC2 key wrapping method is setting LENGTH equal to the length of the CEK, where LENGTH is a single octet.
The second step of the RC2 key wrapping method is forming LCEK by concatenating LENGTH and CEK.
The third step of the RC2 key wrapping method is forming LCEKPAD by concatenating LCEL with PAD, where PAD is the fewest number, including zero, of random octets that make the length of LCEKPAD a multiple of 8.
The fourth step of the RC2 key wrapping method is forming ICV by computing an 8 octet key checksum value on LCEKPAD. The preferred method of forming ICV is by computing a 20 octet message digest on the LCEKPAD using the Secure Hashing Algorithm (SHA-1) and using the most significant, or first, eight octets of the message digest value as ICV.
The fifth step of the RC2 key wrapping method is forming LCEKPADICV by concatenating LCEKPAD with ICV.
The sixth step of the RC2 key wrapping method is forming an initialization vector (IV) by generating 8 random octets.
The seventh step of the RC2 key wrapping method is forming TEMP1 by encrypting LCEKPADICV in CBC mode using a KEK and IV.
The eighth step of the RC2 key wrapping method is forming TEMP2 by concatenating IV and TEMP1.
The ninth step of the RC2 key wrapping method is forming TEMP3 by reversing the order of the octets in TEMP2. That is, swapping the most significant, or first, octet with the least significant, or last, octet, and so on.
The tenth, and last, step of the RC2 key wrapping method is is encrypting TEMP3 in CBC mode using the KEK and 0x4adda22c79e82105 as IV. The length of the resulting ciphertext is 40 octets.
This RC2 key wrapping method requires that a different IV be used when the same CEK is wrapped using a different KEK.
U.S. Pat. No. 5,995,625, entitled “ELECTRONIC CRYPTOGRAPHIC PACKING,” discloses a method of unwrapping wrapped digital data by obtaining an acceptance phrase from a user, deriving a cryptographic key from the acceptance phrase, and unwrapping the wrapped digital data using the derived cryptographic key. The present invention does not derive a key from an acceptance phrase provided by a user. The present invention also differs from U.S. Pat. No. 5,995,625 in other ways as described below. U.S. Pat. No. 5,995,625 is hereby incorporated by reference into the specification of the present invention.
U.S. Pat. Nos. 6,256,733 and 6,260,142, both entitled “ACCESS AND STORAGE OF SECURE GROUP COMMUNICATION CRYPTOGRAPHIC KEYS,” disclose a device for and method of securing stored security credentials by encrypting, by various members of a group, at least a portion of the stored security credentials. The present invention does not require actions by members of a group. The present invention also differs from U.S. Pat. Nos. 6,256,733 and 6,260,142 in other ways as described below. U.S. Pat. Nos. 6,256,733 and 6,260,142 are hereby incorporated by reference into the specification of the present invention.
The present invention is such a secure key management method for AES.